2.06. Метрика, мониторинг и логирование

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Архитектору Инженеру

Метрика, мониторинг и логирование

Стабильность

Системный администратор обеспечивает стабильность — это его главная функциональная ответственность. Стабильность не сводится к отсутствию видимых сбоев; это комплексное свойство, отражающее способность системы сохранять заданный уровень производительности, надёжности и безопасности в условиях внешних и внутренних возмущений — пиковых нагрузок, аппаратных отказов, программных ошибок, сетевых задержек, изменений в конфигурации, действий пользователей и автоматизированных процессов.

Стабильность — это устойчивый режим динамического равновесия. Система может кратковременно выходить из нормы (например, при коротком всплеске запросов к базе данных), но при этом должна не терять функциональность, не нарушать ожиданий пользователей и быстро возвращаться к штатному поведению без вмешательства человека. Такой режим достигается правильной конфигурацией оборудования или ПО, и наличием обратной связи — информации о текущем состоянии, которая позволяет администратору или автоматическим системам принимать решения. Именно этой информацией и занимаются метрики, мониторинг и логирование.

Что такое стабильность системы

В инженерной практике стабильность оценивается по четырём взаимосвязанным критериям:

Доступность (Availability) — способность системы быть готовой к обработке запросов в ожидаемом времени. Это измеримое соотношение между временем безотказной работы и общим календарным временем. Например, договорённость об уровне обслуживания (SLA) может устанавливать требование 99,9 % доступности в месяц. Для критически важных сервисов — 99,99 % и выше. Доступность нарушается при полном отказе и при недоступности отдельных компонентов: база данных «висит», API отвечает кодом 5xx, DNS-запросы теряются.
Надёжность (Reliability) — отсутствие критических сбоев, приводящих к потере данных, нарушению бизнес-процессов или недопустимой задержке реакции. Надёжность выражается в статистической предсказуемости: чем ниже интенсивность отказов и чем короче среднее время их устранения (MTTR), тем выше надёжность. Важно различать отказ и деградацию: сервис может продолжать отвечать, но с задержкой в 30 секунд — формально он «доступен», но ненадёжен для пользователя.
Масштабируемость под нагрузкой (Load tolerance) — способность сохранять стабильные показатели производительности при увеличении объёма запросов, данных или пользователей. Нагрузка может быть штатной (распродажа, отчётный период) или аномальной (DDoS, ошибочный цикл в коде). Система не обязана выдерживать любую нагрузку без изменений, но должна сигнализировать о приближении к границе возможного и не «ломаться» внезапно. Плавное нарастание времени отклика, отказ в приёме новых соединений, активное отбрасывание запросов — это признаки управляемой деградации и лучший вариант, чем неожиданный крах.
Восстанавливаемость (Recoverability) — скорость и предсказуемость возвращения к штатному состоянию после инцидента. Высокая восстанавливаемость подразумевает наличие механизмов резервного копирования, репликации, автоматического переключения, отката конфигурации, а также — и это ключевое — полную прослеживаемость событий, позволяющую точно определить причину сбоя и убедиться, что она устранена. Система, которая падает раз в неделю, но восстанавливается за 30 секунд с полным сохранением данных, может быть предпочтительнее той, что «не падает», но при первом же серьёзном сбое требует ручного вмешательства в течение нескольких часов.

Эти четыре аспекта не существуют изолированно. Например, плохая восстанавливаемость приводит к росту MTTR, что напрямую снижает доступность. Деградация под нагрузкой может маскировать надвигающийся отказ — если администратор не видит ранних симптомов, он не успеет принять превентивные меры. Поэтому для поддержания стабильности необходима непрерывная диагностика состояния системы, основанная на трёх взаимодополняющих процессах: измерении (метрики), наблюдении (мониторинг) и фиксации (логирование).

Признаки нестабильности

Системный администратор не ждёт, пока сервис упадёт — он отслеживает предвестники нестабильности. Эти признаки делятся на три группы: технические, поведенческие и временные.

Технические признаки — отклонения в значениях базовых метрик:

Рост загрузки CPU не сопровождается ростом бизнес-метрик (например, количество запросов не изменилось, а CPU вырос с 30 % до 80 % — возможна утечка памяти, бесконечный цикл, блокировка);
Снижение свободной памяти при одновременном росте swap-активности — признак нехватки RAM, что ведёт к замедлению всех операций;
Рост времени отклика диска (latency), особенно при малой пропускной способности (throughput) — свидетельствует о фрагментации, аппаратной деградации или конфликтах ввода-вывода;
Рост количества потерянных пакетов, повторных передач (retransmits) в TCP — указывает на проблемы в сети: перегрузку канала, неисправное оборудование, некорректные настройки QoS;
Увеличение количества ошибок в логах приложений: connection refused, timeout, out of memory, deadlock.

Поведенческие признаки — изменения в реакции системы на однотипные действия:

Запросы, которые всегда выполнялись за 100 мс, начали занимать 2–3 секунды;
Пользовательские сценарии проходят нестабильно: один и тот же запрос то успешен, то завершается ошибкой;
Административные операции (рестарт сервиса, деплой) стали занимать значительно больше времени;
Сервис начинает «зависать» при выполнении определённых операций (например, генерация отчётов).

Временные признаки — нарушение ожидаемых временных рамок:

Задания по расписанию (cron, scheduled tasks) выполняются дольше нормы или не завершаются вовсе;
Время доставки уведомлений, обработки сообщений в очередях растёт;
Время ответа на эхо-запросы (ping, healthcheck) увеличивается неравномерно — возможна микрозадержка (microburst), не видимая при усреднении.

Ни один из перечисленных признаков сам по себе не является доказательством нестабильности. Например, кратковременный всплеск CPU — норма при запуске приложения. Диагностическая ценность возникает при комбинации признаков, их повторяемости, отклонении от исторической базовой линии (baseline) и корреляции с внешними событиями (деплой, изменение конфигурации, рост трафика). Именно поэтому системный администратор строит модель нормального поведения системы, относительно которой оценивается любое отклонение.

Измерение стабильности

Стабильность измеряется косвенно — через метрики, отражающие состояние ресурсов, работу сервисов и поведение пользователей. Сами по себе метрики нейтральны: «загрузка CPU 95 %» — это не «плохо», пока не известно, какая у системы роль, каков её профиль нагрузки и как долго длится такой уровень. Поэтому ключевой принцип измерения — контекстуализация.

Метрики делятся на три категории в зависимости от уровня абстракции:

Системные (инфраструктурные) метрики — отражают состояние физической или виртуальной машины:
- Процессор: время в пользовательском и системном режиме, ожидание ввода-вывода (iowait), прерывания, частота;
- Память: общая, свободная, кэшированная, подкачка (swap in/out), анонимные страницы;
- Дисковая подсистема: количество операций чтения/записи в секунду (IOPS), объём данных (throughput), среднее время операции (latency), очередь запросов;
- Сеть: пропускная способность, количество соединений, ошибки, переполнения буферов, статистика по интерфейсам и протоколам.
Эти метрики универсальны и не зависят от специфики приложения. Они показывают, хватает ли ресурсов для работы. Однако их недостаточно для понимания, почему ресурсы исчерпаны.
Сервисные (прикладные) метрики — отражают работу конкретных компонентов ПО:
- Веб-сервер: количество запросов в секунду, распределение по HTTP-статусам, время обработки запроса, размер очереди соединений;
- База данных: время выполнения запросов, количество активных сессий, hit ratio кэша буферов, блокировки, репликация lag;
- Очередь сообщений: длина очереди, скорость публикации и потребления, количество dead-letter сообщений;
- Контейнеры и оркестраторы: количество рестартов подов, использование лимитов CPU/memory, сетевые ошибки между сервисами.
Эти метрики позволяют локализовать проблему внутри стека. Например, высокая загрузка CPU на сервере БД при низкой нагрузке от приложения может указывать на неоптимальный запрос или фоновую задачу.
Бизнес-метрики — отражают ценность системы для пользователя и организацию:
- Количество успешных транзакций, заказов, регистраций;
- Доля ошибок (например, 5xx-ошибок относительно общего числа запросов);
- Время завершения ключевого сценария (например, «открытие корзины до оплаты»);
- Число одновременно активных пользователей, сессий.
Бизнес-метрики — главный индикатор стабильности с точки зрения конечного потребителя. Система может быть технически «здоровой», но если пользователи не могут совершить покупку — она нестабильна в функциональном смысле.

Измерение стабильности требует непрерывного сбора, долгосрочного хранения и взаимной корреляции метрик всех трёх уровней. Только так можно отличить локальную деградацию (например, один «плохой» запрос) от системного сбоя (цепная реакция в микросервисной архитектуре).

Метрики

Метрика — это именованное числовое значение, снабжённое метаданными (таймстемп, теги, источник). Она фиксирует состояние и позволяет строить динамику: как значение менялось во времени. Это принципиально отличает метрику от разового замера.

Типы метрик по характеру изменения:

Gauge (датчик) — мгновенное значение, которое может произвольно расти и падать: объём свободной памяти, температура CPU, количество активных соединений.
Counter (счётчик) — монотонно возрастающее число: общее количество запросов, ошибок, байт, переданных по сети. Для анализа используются скорости изменения (rate, increase).
Histogram и Summary — сложные типы, фиксирующие распределение: например, процентиль времени ответа (p95, p99). Позволяют видеть среднее значение, и «хвосты» — медленные выбросы, которые портят пользовательский опыт.

Метрики, как правило, снабжаются тегами (labels) — пары «ключ=значение», задающие контекст:
http_requests_total{method="POST", endpoint="/api/order", status="200", instance="web-01"}
Теги позволяют гибко агрегировать и фильтровать данные: суммировать запросы по всем инстансам, выделять ошибки только для метода POST, сравнивать производительность разных эндпоинтов.

Важно понимать, что метрика — это агрегированная информация. Она показывает что происходит, но не почему. Для ответа на вопрос «почему» нужны логи и трассировки.

Мониторинг

Мониторинг — это целенаправленный, непрерывный процесс сбора, хранения, анализа и интерпретации данных о состоянии и поведении информационной системы с целью обеспечения её стабильности, диагностики отклонений и поддержки принятия решений.

Это активная инженерная практика, встроенная в жизненный цикл инфраструктуры. Мониторинг начинается на этапе проектирования: уже при выборе архитектуры определяется, какие компоненты будут генерировать метрики, как они будут собираться, где храниться и какие сценарии реагирования предусмотрены.

Важный принцип: мониторинг должен отвечать на конкретные вопросы, а не просто накапливать данные. Примеры таких вопросов:

Работает ли API /health на всех инстансах?
Не приближается ли объём данных в базе к квоте диска?
Не выросло ли время ответа сервиса авторизации выше порога, при котором пользователи начинают жаловаться?
Есть ли признаки аномального поведения — например, резкий спад числа успешных логинов при неизменном трафике?

Если мониторинг не позволяет ответить на подобные вопросы — он сконфигурирован некорректно, независимо от количества графиков и панелей.

Как система выполняет измерения

Существует три основные архитектурные модели сбора метрик. Выбор модели определяется требованиями к производительности, безопасности, масштабируемости и особенностям инфраструктуры.

Pull-модель (опрос «снаружи»)

В этой модели центральная система мониторинга инициирует запросы к наблюдаемым объектам через заранее определённый интерфейс — обычно HTTP-эндпоинт /metrics, возвращающий данные в текстовом формате (например, в формате Prometheus exposition format).

Преимущества:

Высокая предсказуемость: администратор контролирует частоту опроса и объём трафика;
Простота диагностики: если метрики не поступают — проблема на стороне целевого сервиса (не отвечает, блокирует firewall);
Единая точка управления: все правила, таймауты, аутентификация — на стороне сервера мониторинга.

Ограничения:

Требует сетевой доступности целевого сервиса из зоны мониторинга;
Не подходит для ephemeral-объектов (например, короткоживущих заданий в Kubernetes), которые могут исчезнуть до следующего опроса;
Нагрузка на целевой сервис пропорциональна количеству мониторинговых систем (если их несколько).

Pull-модель — основная в экосистеме Prometheus и широко применяется в облачных и контейнерных средах.

Push-модель (передача «изнутри»)

Целевой компонент сам отправляет метрики в центральную систему через API, очередь сообщений (Kafka, RabbitMQ) или специализированный протокол. Часто используется агент, работающий на хосте или в контейнере.

Преимущества:

Подходит для динамических сред: даже кратковременные процессы могут отправить метрики перед завершением;
Гибкость маршрутизации: один агент может отправлять разные данные в разные системы (метрики — в Prometheus, логи — в Loki);
Возможна буферизация при недоступности сервера мониторинга.

Ограничения:

Сложнее обеспечить единообразие: каждый сервис может пытаться отправлять метрики по-своему;
Риск потери данных при сбое агента до отправки;
Требует дополнительных механизмов аутентификации и контроля нагрузки на сервер приёма.

Push-подход доминирует в ELK-стеке (через Filebeat/Logstash), в телеметрии по OpenTelemetry и в Zabbix (при использовании активных проверок).

Гибридная модель

Современные системы часто комбинируют оба подхода. Например:

Prometheus опрашивает долгоживущие сервисы (веб-серверы, базы данных) по pull;
Агенты (node_exporter, cadvisor) собирают системные метрики и предоставляют их через HTTP — тоже pull, но с локальным сбором;
Краткосрочные задачи (batch-процессы) отправляют итоговые метрики по push через Pushgateway (специальный адаптер для Prometheus).

Такой подход позволяет сохранить предсказуемость pull-модели и гибкость push-модели там, где это необходимо.

Агенты

Агент — это программа, устанавливаемая на наблюдаемый хост (физический сервер, виртуальная машина, контейнер), которая выполняет одну или несколько функций:

Сбор системных метрик (CPU, память, диск, сеть), недоступных через стандартные API приложений;
Выполнение активных проверок (например, проверка доступности порта, выполнение SQL-запроса к БД);
Предварительная обработка данных: фильтрация, агрегация, преобразование форматов;
Передача данных в центральную систему (по push) или предоставление эндпоинта для опроса (по pull).

Агент дополняет встроенную телеметрику приложения. Например, веб-сервер может экспортировать собственные метрики (количество запросов, ошибок), а агент — предоставлять данные о загрузке CPU, на котором этот сервер работает. Это позволяет коррелировать прикладные и системные события.

Агент должен быть лёгковесным и изолированным. Его сбой или высокое потребление ресурсов не должны влиять на работу основного сервиса. Современные агенты (например, node_exporter, telegraf, Datadog Agent) используют минимальный объём памяти, работают в пользовательском пространстве и не требуют привилегий root для большинства операций.

SNMP

Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, разработанный в 1988 году и до сих пор широко применяемый для мониторинга сетевого оборудования (коммутаторы, маршрутизаторы, точки доступа), серверов, ИБП, систем охлаждения, даже сканеров и принтеров.

SNMP работает по клиент-серверной модели:

Agent — программный компонент на управляемом устройстве, реализующий SNMP и предоставляющий доступ к Management Information Base (MIB) — иерархической базе данных с описанием управляемых объектов (OID — Object Identifier);
Manager — система мониторинга (Zabbix, LibreNMS, Cacti), отправляющая запросы (GET, GETNEXT, GETBULK) и получающая ответы.

SNMP поддерживает три основных версии:

v1 — устаревшая, без шифрования, аутентификация по community string (открытым текстом);
v2c — улучшенная производительность (bulk-операции), но та же слабая безопасность;
v3 — поддержка шифрования (AES, DES), аутентификации (MD5, SHA), управления доступом на уровне пользователей.

Почему SNMP остаётся актуальным, несмотря на возраст:

Универсальность: почти любое промышленное устройство имеет SNMP-агент «из коробки»;
Минимальные требования к ресурсам: реализация возможна даже на микроконтроллерах;
Богатая модель данных: MIB описывает текущие значения, пороги, истории, события (traps).

Ограничения:

Сложность работы с MIB: необходимы соответствующие файлы для декодирования OID;
Отсутствие встроенной поддержки push-модели (хотя traps частично её компенсируют);
Низкая выразительность: SNMP передаёт скалярные значения, но не временные ряды, не распределения, не структурированные события.

В современных инфраструктурах SNMP часто используется как «мост» для включения legacy-оборудования в единую систему мониторинга, а не как основной метод для приложений.

Алертинг

Мониторинг без алертинга — это запись истории. Алертинг — это механизм оперативного информирования о событиях, требующих внимания. Но важно: алерт не должен быть простой реакцией на превышение порога. Это распространённая ошибка, ведущая к «алерт-усталости» (alert fatigue), когда администраторы игнорируют уведомления из-за их избыточности.

Корректный алертинг строится на трёх принципах:

Ситуативность — срабатывание только при условии, что отклонение:
- Устойчиво (не кратковременный всплеск);
- Значимо (превышает шумовой фон);
- Коррелирует с другими индикаторами (например, рост ошибок + рост latency).
Градация критичности — не все события равнозначны:
- Warning — потенциальная проблема, требующая наблюдения (например, диск заполнен на 85 %);
- Critical — текущий инцидент, нарушающий SLA (диск заполнен на 98 %, сервис недоступен);
- Info — информационное событие без немедленного воздействия (рестарт сервиса по расписанию).
Информативность — уведомление должно содержать:
- Что произошло (наименование метрики, значение, порог);
- Где произошло (хост, сервис, окружение);
- Когда (точное время события);
- Почему это важно (ссылка на документацию, возможные последствия);
- Что можно сделать (рекомендации, ссылка на runbook).

Современные системы (Prometheus Alertmanager, Zabbix escalation) поддерживают группировку схожих алертов, подавление дубликатов, маршрутизацию по каналам (email, Slack, Telegram, PagerDuty) и интеграцию с системами управления инцидентами.

Логирование

Логирование — это целенаправленный процесс записи событий, происходящих в системе, с указанием времени, источника, контекста и уровня значимости. В отличие от метрик, которые показывают состояние системы в виде агрегированных числовых значений, логи фиксируют последовательность действий и конкретные инциденты — «что, когда, откуда и при каких условиях произошло».

Лог — это не просто «ошибка в консоли». Это структурированная или полуструктурированная запись, предназначенная для:

Диагностики сбоев: поиск корневой причины (root cause analysis) по цепочке событий;
Аудита действий: фиксация операций пользователей, администраторов и автоматизированных систем;
Соблюдения требований регуляторов (PCI DSS, GDPR, ФЗ-152, ГОСТ Р ИСО/МЭК 27001);
Анализа поведения: выявление аномалий, мошеннических действий, неоптимальных сценариев;
Восстановления после инцидентов: точное знание, что было изменено и когда.

Главная инженерная задача логирования — обеспечить полноту без избыточности, надёжность без перегрузки и доступность без уязвимости. Слишком мало логов — невозможно проанализировать инцидент; слишком много — замедляется система, растут затраты на хранение, затрудняется поиск. Баланс достигается осознанным выбором: что, на каком уровне детализации и на каком этапе жизненного цикла логировать.

Уровни логирования

Современные системы логирования используют иерархическую модель уровней (log levels), определяющих важность записи. Порядок строго восходящий — события более высокого уровня включают в себя все более низкие:

TRACE — максимально детальная отладочная информация: вход/выход из методов, значения переменных, состояние объектов. Используется исключительно при разработке или глубокой диагностике. В эксплуатации, как правило, отключён.
DEBUG — информация, полезная для понимания внутреннего поведения приложения: инициализация компонентов, выбор конфигурации, промежуточные результаты вычислений. Включается временно при расследовании проблем.
INFO — ключевые этапы нормальной работы: запуск/остановка сервиса, успешная обработка крупных операций (загрузка данных, генерация отчёта), смена состояния системы. Это основной уровень для мониторинга жизненного цикла.
WARN — события, не нарушающие работу, но требующие внимания: использование устаревшего API, превышение рекомендованного порога, восстановление после временной ошибки (retry succeeded), неоптимальный путь выполнения.
ERROR — сбой операции, при котором запрос или задача не завершена успешно, но система продолжает работать: исключение в обработчике, недоступность внешнего сервиса с fallback, некорректные входные данные.
FATAL (CRITICAL) — катастрофическое событие, приводящее к остановке компонента или невозможности продолжения работы: нехватка памяти, отсутствие критического конфигурационного файла, фатальное исключение на уровне процесса.

Правильная настройка уровней — критически важна. Например, запись паролей или персональных данных на уровне INFO или DEBUG — грубое нарушение безопасности. Включение TRACE в продакшене — прямой путь к дисковому переполнению.

Структурированное логирование

Традиционный подход — запись в формате свободного текста:
2025-11-18 14:30:05 [ERROR] Database connection failed: timeout after 5000ms

Этот формат плохо масштабируется: поиск по полю duration, агрегация по error_type, корреляция по request_id требуют регулярных выражений и ручной обработки.

Структурированное логирование — это запись событий в виде машиночитаемых объектов (обычно JSON), где каждое поле имеет чёткое назначение:

{
  "timestamp": "2025-11-18T14:30:05.123Z",
  "level": "error",
  "service": "order-api",
  "instance": "order-api-7d5c8b9f4-2xklm",
  "trace_id": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8",
  "span_id": "o9p0q1r2",
  "event": "db_connection_timeout",
  "duration_ms": 5000,
  "db_host": "postgres.prod",
  "db_port": 5432,
  "user_id": "usr_8831"
}

Преимущества:

Прямая индексация полей без парсинга;
Возможность построения аналитических запросов («все ошибки подключения к БД за последние 24 ч с duration_ms > 3000»);
Естественная интеграция с системами поиска и визуализации (Elasticsearch, Loki);
Поддержка распределённой трассировки через trace_id и span_id.

Переход к структурированному формату — архитектурное решение, требующее согласования между разработчиками, администраторами и аналитиками на уровне соглашения о схеме (schema convention).

Системные журналы в Linux

В Linux существует два основных механизма системного логирования, часто работающих совместно:

systemd-journald

Ядро современной системы логирования в дистрибутивах с systemd. journald — это фоновый демон, который:

Собирает логи ядра (через /dev/kmsg), демонов systemd (через sd_journal_send()), stdin/stderr сервисов;
Хранит записи в бинарном, индексированном формате в /var/log/journal/;
Поддерживает богатые метаданные: UID/GID, cgroup, SELinux context, boot ID, hostname;
Обеспечивает быстрый поиск по полям (journalctl _COMM=sshd PRIORITY=3);
Может перенаправлять логи в syslog-совместимые системы.

Особенность: журнал по умолчанию может храниться только в памяти (volatile) или на диске (persistent). Это позволяет гибко управлять требованиями к надёжности и производительности.

rsyslog / syslog-ng

Классические syslog-демоны, реализующие стандарт RFC 5424. Они:

Принимают сообщения по UDP/TCP/Unix-сокетам;
Гибко маршрутизируют их по правилам (фильтрация по facility, severity, содержимому);
Записывают в файлы, базы данных, отправляют по сети (в том числе в формате JSON);
Обеспечивают долгосрочное хранение и архивацию (rotation, compression).

Современная практика: journald служит первичным сборщиком (особенно для служб systemd), а rsyslog — как транспортный и архивный слой. journald передаёт сырые записи в rsyslog, который уже решает, куда их направить: в локальные файлы /var/log/, в централизованную систему (например, Elasticsearch) или в облачный бакет.

Ключевые лог-файлы в традиционной схеме:

/var/log/messages или /var/log/syslog — общие системные сообщения;
/var/log/auth.log — события аутентификации (SSH, sudo, PAM);
/var/log/kern.log — сообщения ядра;
/var/log/dpkg.log, /var/log/yum.log — действия пакетного менеджера.

Системные журналы в Windows

Журнал событий Windows (Windows Event Log) — это централизованная, типизированная и защищённая подсистема, в отличие от децентрализованных текстовых файлов Linux. События записываются в иерархию журналов (logs), разделённых по назначению:

Application — события от приложений, использующих Windows API (ReportEvent);
System — события от драйверов, служб и ядра ОС;
Security — события аудита: вход в систему, доступ к объектам, изменения политик;
Setup, ForwardedEvents, HardwareEvents и др. — специализированные журналы.

Каждая запись содержит:

Уникальный идентификатор события (EventID);
Уровень (Information, Warning, Error, Critical, Verbose);
Источник (имя службы или приложения);
Время создания;
Детализированные данные (XML-блок с параметрами — EventData, UserData);
Контекст безопасности (SID пользователя, домен).

Для работы используются:

eventvwr.msc — графический просмотрщик;
wevtutil — командная утилита управления (экспорт, очистка, настройка подписок);
PowerShell (Get-WinEvent, Get-EventLog) — для автоматизации и фильтрации;
WEF (Windows Event Forwarding) и WEC (Windows Event Collector) — для централизованного сбора в доменной среде.

Важно: журнал Security требует явного включения политики аудита (Local Security Policy → Audit Policy). Без этого критически важные события (например, неудачные попытки входа) не фиксируются.

Логи приложений

Прикладные логи генерируются самими программами и могут храниться по-разному:

Локальные файлы (app.log, error.log) — простой, но ненадёжный способ. Проблемы:
- Отсутствие ротации → заполнение диска;
- Сложность сбора с множества серверов;
- Нет защиты от подделки.
stdout/stderr контейнера — стандарт в Docker/Kubernetes. Логи захватываются движком контейнеризации и могут быть:
- Перехвачены агентом (например, Fluent Bit) и отправлены в централизованную систему;
- Записаны в файлы на хосте через volume;
- Отправлены напрямую в stdout контейнера, где их считывает sidecar-агент.
Сетевая передача — приложение само отправляет логи по TCP/UDP/gRPC в агgregator (например, в Loki, Elasticsearch или syslog-сервер). Преимущество — отказоустойчивость (буферизация, retry), недостаток — зависимость от сети и усложнение конфигурации приложения.

Современный паттерн — логирование в stdout + sidecar-агент. Приложение ничего не знает о конечной системе хранения: оно пишет структурированный JSON в stdout. Агент, работающий в том же Pod (Kubernetes) или на хосте, собирает поток, обогащает метаданными (namespace, pod name, labels), сжимает и отправляет в центр.

Логи аудита

Аудиторские логи — особый класс, регулируемый законодательно и политиками безопасности. Их цель — восстановить цепочку действий с привязкой к субъекту.

Ключевые требования:

Непротиворечивость: запрет на удаление или изменение записей (write-once, append-only);
Привязка к идентификатору: CN=Timur.Tagirov,OU=IT,O=Corp;
Покрытие критических операций: вход в систему, повышение привилегий (sudo, runas), изменение политик, доступ к конфиденциальным данным, изменение конфигурации безопасности;
Синхронизация времени: использование NTP с единым источником для всех узлов.

В Linux аудит обеспечивается подсистемой auditd (Linux Audit Framework), которая работает на уровне ядра и фиксирует системные вызовы (execve, open, setuid) по заданным правилам (auditctl -a always,exit -F arch=b64 -S execve).

В Windows — через Advanced Audit Policy, где можно настроить детализацию по категориям:

Account Logon, Logon/Logoff
Object Access (файлы, реестр, сетевые ресурсы)
Privilege Use (назначение прав)
Policy Change

Аудиторские логи почти никогда не анализируются в реальном времени. Их основное применение — постфактумное расследование инцидентов, проверки на соответствие и судебные экспертизы.

Жизненный цикл логов

Управление логами — это процесс с чёткими этапами:

Этап	Описание	Типичные инструменты
Генерация	Запись события приложением или системой	`logger`, `syslog()`, `console.log`, библиотеки (log4j, NLog, Winston)
Сбор и буферизация	Агрегация потоков, защита от потерь при недоступности получателя	`rsyslog`, `fluentd`, `vector`, `filebeat`
Транспортировка	Передача в централизованную систему	HTTP/HTTPS, gRPC, Kafka, AMQP
Индексация и хранение	Поиск по содержимому, метаданным, временным диапазонам	Elasticsearch, OpenSearch, Loki (на базе объектного хранилища)
Визуализация и анализ	Построение дашбордов, поисковых запросов, алертов по логам	Kibana, Grafana (с Loki), Splunk
Архивация и утилизация	Перемещение «тёплых» данных в долгосрочное хранилище, удаление по политике	S3/GCS buckets, Glacier, автоматические политики retention

Ключевой параметр — политика хранения (retention policy). Она определяет:

Сколько дней логи хранятся в «горячем» хранилище (быстрый поиск);
Когда и куда они перемещаются в «холодное» (медленный, дешёвый доступ);
Через сколько удаляются полностью.

Политика должна балансировать между операционными, юридическими и финансовыми требованиями. Например:

Системные логи — 30 дней «горячо», 180 дней «холодно»;
Логи аудита — 365 дней (требование PCI DSS);
Логи приложений — 7–14 дней, если не требуется иное.

Prometheus

Prometheus — это open-source система мониторинга и алертинга, изначально разработанная в SoundCloud и ставшая де-факто стандартом для cloud-native сред. Её архитектура выстроена вокруг трёх ключевых концепций: pull-модель, модель данных временных рядов, многоуровневая агрегация.

Архитектурные компоненты

Prometheus Server — ядро системы:
- Retrieval — подсистема опроса (scraping) эндпоинтов /metrics по заданному расписанию (от 5 секунд и выше);
- TSDB (Time Series Database) — локальная база данных, оптимизированная под запись и выборку временных рядов с сжатием на диске;
- HTTP API и Web UI — интерфейс для запросов и визуализации (базовой);
- Rule Engine — выполнение правил записи (recording rules) и алертинга (alerting rules).
Экспортеры (exporters) — адаптеры для систем, не предоставляющих метрики в формате Prometheus:
- node_exporter — сбор системных метрик Linux/Windows;
- mysqld_exporter, postgres_exporter — метрики баз данных;
- blackbox_exporter — проверка доступности по HTTP, TCP, ICMP, DNS;
- snmp_exporter — интеграция с SNMP-устройствами.
  Экспортёр запускается рядом с целевым сервисом и транслирует его внутреннюю статистику в HTTP-эндпоинт с текстовым форматом.
Pushgateway — компонент для приёмки метрик от краткосрочных заданий (batch-процессов, CI/CD-стадий), которые не могут быть опрошены по pull. Работает как буфер: задание отправляет метрики по push, Prometheus опрашивает Pushgateway как обычный эндпоинт.
Alertmanager — отдельный сервис, управляющий жизненным циклом алертов:
- Группировка (grouping) — объединение похожих алертов (например, по job или cluster);
- Подавление (inhibition) — отключение вторичных алертов при наличии первичного (например, «сервис недоступен» подавляет «высокая latency» для того же сервиса);
- Маршрутизация — направление уведомлений в разные каналы (email, Slack, PagerDuty) в зависимости от меток.

Модель данных и язык запросов

Prometheus хранит данные как множество временных рядов, каждый из которых идентифицируется:

Именем метрики (например, http_requests_total);
Набором пар «ключ=значение» — метками (labels): {job="api", instance="10.0.1.5:8080", method="POST", status="500"}.

Язык запросов PromQL позволяет:

Выбирать ряды по имени и меткам (http_requests_total{status=~"5.."});
Вычислять скорости (rate(http_requests_total[5m]));
Агрегировать по меткам (sum by (job) (rate(http_requests_total[5m])));
Сравнивать текущее значение с историческим (http_requests_total > avg_over_time(http_requests_total[1h]) * 1.5).

Важно: Prometheus не предназначен для долгосрочного хранения (по умолчанию — 15 дней). Для архивации используются внешние решения: Thanos, Cortex, Mimir или запись в InfluxDB/OpenTSDB через remote_write.

Особенности развёртывания

Однонодовая установка подходит для тестовых сред и небольших инфраструктур (< 100 целей);
Для горизонтального масштабирования применяются:
- Sharding — разделение целей между несколькими серверами Prometheus по меткам;
- Federation — агрегация данных из нескольких Prometheus-серверов на центральном уровне;
- Thanos/Cortex — глобальный запросный слой с долгосрочным хранением в объектном хранилище (S3, GCS).
Конфигурация задаётся в YAML, поддерживает service discovery (Kubernetes, Consul, DNS) для динамического обнаружения целей.

Prometheus — не универсальная система. Он не подходит для:

Логирования (нет полнотекстового поиска);
Трассировки (хотя интегрируется с Jaeger/Tempo через trace_id в логах);
Мониторинга чёрного ящика без экспортеров (требуется либо встраивание клиента, либо blackbox_exporter с ограниченной детализацией).

Zabbix

Zabbix — enterprise-ориентированная open-source платформа, сочетающая мониторинг метрик, логов, сетевых устройств и бизнес-процессов в едином веб-интерфейсе. Её ключевое преимущество — единая модель управления для разнородных активов: физические серверы, виртуальные машины, сетевые устройства, облачные сервисы, пользовательские сценарии.

Архитектура

Zabbix Server — центральный процесс:
- Управляет расписанием сбора данных;
- Хранит конфигурацию, историю, триггеры, действия;
- Работает с СУБД (PostgreSQL, MySQL, Oracle) как основным хранилищем.
Zabbix Proxy — промежуточный агент для распределённых сред:
- Собирает данные от хостов в удалённом офисе или облаке;
- Буферизует их при недоступности сервера;
- Снижает нагрузку на центральный сервер и сетевой трафик.
Zabbix Agent — лёгкий компонент, устанавливаемый на наблюдаемый хост:
- Поддерживает пассивные проверки (сервер запрашивает данные по TCP);
- Поддерживает активные проверки (агент сам отправляет данные по расписанию);
- Может выполнять локальные скрипты, собирать данные из JMX, SNMP, IPMI.
Zabbix Frontend — веб-интерфейс на PHP, предоставляющий:
- Настройку хостов, шаблонов, триггеров;
- Визуализацию (графики, сводные экраны, карты);
- Управление инцидентами и отчётность.

Модель конфигурации

Zabbix строится вокруг шаблонов (templates) — многократно используемых наборов:

Элементов данных (items) — что и как собирать (CPU, свободное место, выполнение скрипта);
Триггеров (triggers) — логические выражения на основе данных (например, {host:system.cpu.load[all,avg1].last()}>5);
Графиков, карт, правил обнаружения.

Шаблоны наследуются, могут включать другие шаблоны (например, «Linux Server» включает «Network Interface» и «Filesystem»), что обеспечивает консистентность.

Особенности

Auto-discovery — автоматическое обнаружение сетевых устройств, файловых систем, JMX-бивов, Docker-контейнеров;
Low-level discovery (LLD) — динамическое создание элементов на основе шаблонов (например, появился новый диск — Zabbix сам добавит метрики для него);
Web monitoring — проверка пользовательских сценариев («зайти на сайт → кликнуть → проверить текст»);
Действия (actions) — реакция на события: отправка уведомлений, выполнение скриптов, интеграция с ITSM-системами (Jira, ServiceNow).

Zabbix хорошо подходит для:

Гибридных инфраструктур (on-prem + облако);
Сред с большим количеством legacy-оборудования (благодаря SNMP, IPMI, SSH-проверкам);
Организаций, где требуется единая точка управления и аудит всех действий.

Ограничения:

Монолитная архитектура сервера может стать узким местом при > 100 тыс. элементов данных;
Менее гибок в аналитике по сравнению с PromQL;
Веб-интерфейс требует значительных ресурсов при большом числе пользователей.

Grafana

Grafana — платформа визуализации и анализа, способная подключаться к десяткам источников. Её основная функция — превращать сырые данные в понятные, интерактивные и действенные представления.

Ключевые возможности

Единый интерфейс для разнородных данных:
- Метрики: Prometheus, Zabbix, InfluxDB, Graphite, MySQL, PostgreSQL;
- Логи: Loki, Elasticsearch, Splunk, CloudWatch Logs;
- Трассировки: Tempo, Jaeger, Zipkin;
- Алерты: из любого поддерживаемого источника или через Grafana Alerting.
Дашборды с переменными — параметризация панелей:
- Выбор окружения (prod, stage), кластера, сервиса через выпадающий список;
- Автоподстановка в запросы (rate(http_requests_total{job="$job"}[5m]));
- Временные переменные ($__interval для адаптивного сглаживания).
Аннотации — наложение событий на графики:
- Деплои (из CI/CD: GitLab, Jenkins);
- Ручные заметки («переконфигурация сети»);
- Алерты (визуальная привязка к пику ошибок).
Grafana Alerting (Unified Alerting) — централизованное управление алертами:
- Определение правил в виде запросов к источникам данных;
- Гибкие условия (пороги, изменения во времени, статистические отклонения);
- Маршрутизация через контактные точки (notification policies);
- Поддержка silence (тишина) и группировка.

Архитектурные аспекты

Backend — Go-сервис, управляющий аутентификацией, RBAC, сохранением дашбордов;
Frontend — React-приложение, работающее в браузере;
Plugins — расширения для поддержки новых источников данных и панелей;
Grafana Cloud / Enterprise — управляемые и расширенные версии с поддержкой SLA, SSO, аудита.

Grafana не заменяет Prometheus или Zabbix — она дополняет их, предоставляя:

Единое окно для сопоставления метрик, логов и трассировок («correlation»);
Возможность создания executive-дашбордов для менеджмента;
Инструменты для ad-hoc анализа («а что было в этот момент в логах?»).

ELK Stack

Термин ELK Stack (Elasticsearch, Logstash, Kibana) исторически обозначал стек для централизованного логирования. Сегодня он трансформировался в Elastic Stack, включающий:

Elasticsearch — распределённая поисковая и аналитическая база данных на базе Apache Lucene;
Kibana — веб-интерфейс для визуализации, анализа и управления;
Beats — лёгкие агенты сбора (Filebeat — логи, Metricbeat — метрики, Auditbeat — аудит, Heartbeat — uptime);
Ingest Pipelines — преобразование данных внутри Elasticsearch (парсинг, обогащение, фильтрация);
Machine Learning — обнаружение аномалий без задания порогов.

Почему Logstash уступает место Beats и Ingest Pipelines

Logstash — мощный ETL-процессор на JVM, поддерживающий сотни входов, фильтров и выходов. Но он:
- Требует значительных ресурсов (CPU, память);
- Сложен в конфигурировании (DSL на основе Ruby-подобного синтаксиса);
- Чаще используется как централизованный процессор для тяжёлых преобразований.
Beats — написаны на Go, потребляют минимум ресурсов, поддерживают TLS, сжатие, буферизацию. Они:
- Собирают данные на хосте;
- Отправляют напрямую в Elasticsearch или через Kafka/Redis;
- Позволяют делегировать парсинг в Ingest Pipelines (на стороне ES), упрощая развёртывание.

Модель данных и поиск

Elasticsearch хранит данные в индексах, разделённых на шарды. Каждая запись (документ) — JSON-объект с динамической схемой (mapping).

Kibana предоставляет:

Discover — интерактивный поиск по полям, фильтрация, сохранение запросов;
Dashboard — композиция визуализаций (графики, таблицы, геокарты);
Logs App — специализированный интерфейс для работы с логами (поиск по уровню, сервису, trace_id);
Alerting — триггеры по условиям (threshold, anomaly, machine learning).

Современные альтернативы и гибриды

PLG-стек (Prometheus + Loki + Grafana) — более лёгкий и экономичный подход:
- Loki — «Prometheus для логов»: индексирует только метки, хранит тело логов в объектном хранилище;
- LogQL — язык запросов, схожий с PromQL;
- Подходит для облачных сред с ограниченным бюджетом на хранение.
EFK (Elasticsearch + Fluentd/Fluent Bit + Kibana) — популярный вариант в Kubernetes:
- Fluent Bit — ультралёгкий агент сбора (в 10–20 раз легче Filebeat);
- Fluentd — централизованный процессор (аналог Logstash, но на Ruby/C).
OpenSearch — форк Elasticsearch (вследствие изменения лицензии Elastic NV), с Kibana-совместимым OpenSearch Dashboards. Используется в AWS, Red Hat, и других, где важна лицензионная независимость.

Выбор стека определяется:

Требованиями к скорости поиска (Elasticsearch быстрее Loki для full-text);
Бюджетом на хранение (Loki дешевле в 5–10 раз при том же объёме логов);
Необходимостью аналитики в реальном времени (Elastic ML vs Loki с Grafana ML-плагинами);
Политикой open-source в организации.

Три столпа наблюдаемости

Термин observability (наблюдаемость) ввёл в обиход инженерный подход, при котором стабильность системы обеспечивается реакцией на сбои и способностью понять внутреннее состояние по внешним проявлениям — даже в отсутствие заранее заданных метрик или логов. Для этого используется три взаимодополняющих источника данных:

Метрики — отвечают на вопрос «Что происходит в системе в целом?»
Они предоставляют сжатое, агрегированное представление о состоянии: нагрузка, доступность, производительность. Метрики эффективны для обнаружения аномалий, построения базовых линий и алертинга по порогам. Однако они не объясняют почему: почему выросла latency? Какой конкретно запрос её вызвал?
Логи — отвечают на вопрос «Что произошло и в какой последовательности?»
Логи фиксируют дискретные события с контекстом: ошибка валидации, неудачная авторизация, запуск задачи. Они позволяют восстановить цепочку действий, но только если событие было залогировано. При высокой нагрузке логирование всех запросов становится накладным, а поиск иголки в стоге сена — медленным.
Трассировки (tracing) — отвечают на вопрос «Как конкретный запрос прошёл через систему?»
Распределённая трассировка фиксирует путь одного запроса через микросервисы, базы данных, очереди, внешние API. Каждая операция — span — содержит время начала, длительность, метаданные, ошибки. Объединяя spans по общему trace_id, можно увидеть «бутылочные горлышки», каскадные сбои, неоптимальные вызовы. Трассировка не заменяет логи — она структурирует их в контексте запроса.

Интеграция — обязательна. Например:

Алерт по метрике http_request_duration_seconds{quantile="0.99"} > 2s → переход в Grafana → фильтрация логов по trace_id, найденному через Tempo/Jaeger → просмотр конкретной трассировки → локализация медленного SQL-запроса в логе БД → оптимизация индекса.
Без сквозного trace_id, передаваемого через заголовки (например, traceparent по стандарту W3C), такая корреляция невозможна.

Современные стандарты (OpenTelemetry) обеспечивают единый способ генерации всех трёх типов данных из одного источника, устраняя фрагментацию инструментов.

Стратегия построения системы наблюдаемости

Внедрение мониторинга часто начинается с тактики: «сервер упал — поставим Zabbix». Такой подход ведёт к «островкам наблюдаемости» — разрозненным дашбордам, несогласованным метрикам, дублирующим алертам. Системный подход предполагает поэтапное развитие:

Этап 1. Базовая стабильность (реактивный мониторинг)

Цель: обнаружение полных отказов и критических ресурсных перегрузок.
Показатели: доступность сервисов (HTTP 200 на /health), загрузка CPU > 95 %, свободное место на диске < 5 %, память swap > 0.
Инструменты: node_exporter + Prometheus + Alertmanager или Zabbix с простыми триггерами.
Результат: администратор узнаёт о проблеме после её возникновения, но до жалоб пользователей.

Этап 2. Диагностическая глубина (корреляционный мониторинг)

Цель: сокращение MTTR (Mean Time To Repair) за счёт быстрой локализации причины.
Показатели: распределение ошибок по типам (4xx/5xx), latency по эндпоинтам, correlation между метриками и логами (например, рост go_goroutines + логи deadlock detected).
Инструменты: структурированное логирование, trace_id в логах, дашборды в Grafana с перекрёстными ссылками.
Результат: время диагностики сокращается с часов до минут.

Этап 3. Проактивное управление (прогностический мониторинг)

Цель: предотвращение инцидентов до нарушения SLA.
Показатели: SLO (Service Level Objectives) и SLI (Service Level Indicators), error budgets, статистические аномалии (например, рост p99 latency на 20 % за 1 час при неизменной нагрузке).
Инструменты: машинное обучение (Anomaly Detection в Elastic, Prophet в Grafana), SLO-расчёты в Prometheus (через recording rules), автоматизированные runbook’и при приближении к budget burn rate.
Результат: администратор получает сигнал до того, как пользователь заметит проблему.

Этап 4. Наблюдаемость как часть жизненного цикла

Цель: встраивание телеметрии в каждый этап разработки и эксплуатации.
Показатели: покрытие кода логами (log coverage), наличие метрик для всех критических путей, автоматические проверки при деплое («если latency вырос на 50 % — откат»).
Инструменты: OpenTelemetry SDK в коде, synthetic monitoring (Healthchecks, Checkly), chaos engineering (Gremlin, Chaos Mesh) с мониторингом реакции.
Результат: стабильность становится свойством системы, а не результатом героических усилий администратора.

Анти-паттерны и типичные ошибки

Даже при использовании передовых инструментов можно создать систему, которая вводит в заблуждение. Вот наиболее распространённые ошибки:

1. Алертинг по метрикам без контекста

Ошибка: CPU > 80% → CRITICAL.
Проблема: на многоядерной машине кратковременный всплеск до 100 % на одном ядре — норма; фоновая задача может легально использовать 99 % CPU.
Решение: алерт по устойчивому превышению, с учётом profile’я сервиса: avg_over_time(node_cpu_seconds_total{mode="idle"}[10m]) < 0.1 и rate(http_requests_total[5m]) < 0.1 * avg(rate(http_requests_total[1h])) (низкая нагрузка при высокой загрузке — признак зацикливания).

2. Логирование всего «на всякий случай»

Ошибка: запись всех запросов на уровне DEBUG в продакшен.
Проблема: переполнение диска, снижение производительности, утечка персональных данных.
Решение: динамическое логирование (feature flags), sampling (запись 1 % ошибок), строгая политика уровней и masking конфиденциальных полей.

3. Отсутствие сквозной идентификации

Ошибка: trace_id генерируется в каждом микросервисе заново.
Проблема: невозможность проследить запрос от фронтенда до БД.
Решение: единый стандарт передачи traceparent (W3C Trace Context) через HTTP-заголовки, gRPC metadata, сообщения очередей.

4. Мониторинг только «своего» компонента

Ошибка: команда БД следит за pg_stat_activity, команда API — за http_requests_total, но никто не смотрит на roundtrip_time = latency_api + latency_db.
Проблема: инциденты «проваливаются» между командами.
Решение: end-to-end метрики и SLO, принадлежащие владельцу бизнес-процесса, а не технологии.

5. Игнорирование стоимости наблюдаемости

Ошибка: хранение всех логов в Elasticsearch «горячими» 180 дней.
Проблема: затраты на инфраструктуру превышают стоимость самого приложения.
Решение: tiered storage (hot/warm/cold/archive), агрегация логов в метрики (например, count_over_time({job="app"} |= "ERROR")[1h] → app_errors_total), использование Loki для raw-логов.

Роль системного администратора в эпоху наблюдаемости

Традиционный администратор «чинил серверы». Современный — проектирует устойчивость. Его компетенции расширились:

Архитектор телеметрии: определяет, какие метрики, логи и трассировки необходимы для удовлетворения SLO, проектирует схемы меток, политики хранения, топологию сбора.
Инженер интеграции: настраивает обмен данными между системами (например, передача event’ов из Zabbix в Grafana, экспорт метрик в OpenTelemetry Collector).
Аналитик инцидентов: владеет методами RCA (5 Whys, Fishbone), умеет строить causal graphs из метрик и логов.
Наставник разработчиков: внедряет культуру наблюдаемости в команды: «если функция не имеет метрик — она не готова к продакшену».
Хранитель данных: обеспечивает соответствие требованиям регуляторов по аудиту, шифрованию, retention.

Ключевой сдвиг — от реакции к предсказанию, от локального ремонта к системному дизайну, от владения сервером к ответственности за пользовательский опыт.

Перспективы

OpenTelemetry как стандарт де-факто
Проект CNCF, объединяющий OpenTracing и OpenCensus, обеспечивает единый SDK, API и протокол (OTLP) для генерации метрик, логов и трассировок. Внедрение OTel устраняет vendor lock-in и упрощает замену бэкендов (например, переход с Jaeger на Tempo без изменения кода).
eBPF — наблюдаемость на уровне ядра без изменения приложений
Технология позволяет безопасно внедрять код в ядро Linux для сбора:
- Сетевой статистики по соединениям (без tcpdump);
- Времени выполнения системных вызовов;
- Блокировок и contention’а в приложениях.
  Инструменты: Pixie, Parca, Datadog eBPF Monitoring.
SLO-ориентированный мониторинг
Вместо «CPU < 80 %» — «99.9 % запросов должны завершаться за < 500 мс в течение 30 дней». Error budget становится ключевым индикатором: если он исчерпан — новые фичи не выпускаются до стабилизации.
Объединение security и observability (SecObser)
Логи аудита, сетевые потоки, аномалии в поведении — всё это анализируется едиными pipeline’ами для обнаружения атак (например, рост sudo для неадминистративных учётных записей + необычный outbound-трафик).
Автономные системы диагностики
AI/ML-модели, обученные на исторических инцидентах, предлагают гипотезы о причинах сбоев и рекомендуют действия — «вероятно, утечка памяти в order-service, проверьте heap dump».

Практикум: типовые сценарии диагностики и реагирования

Теория наблюдаемости реализуется в практике через структурированный подход к расследованию инцидентов. Опытный администратор движется по заранее отработанной методике, минимизируя время простоя и избегая ложных гипотез. Ниже — разбор пяти классических ситуаций, демонстрирующих, как метрики, логи и трассировки применяются в связке.

Сценарий 1. Сервис стал отвечать медленно, но не падает

Симптомы: пользователи жалуются на «тормоза», 5xx-ошибок нет, доступность по /health — 100 %.

Шаг 1. Уточнение: что замедлилось?

Проверяется дашборд по бизнес-метрикам:
- Время завершения ключевых сценариев (например, «оформление заказа»);
- Распределение времени ответа по эндпоинтам (http_request_duration_seconds_bucket).
Вывод: замедление только в /api/checkout, остальные эндпоинты в норме.

Шаг 2. Локализация: где возникает задержка?

Сравнивается:
- Время ответа на уровне ingress-контроллера (например, Nginx upstream_response_time);
- Время обработки в самом приложении (http_request_duration_seconds внутри сервиса).
Если upstream_response_time ≈ приложение — проблема в коде или БД;
Если upstream_response_time >> приложение — проблема в сети, DNS, TLS-handshake, балансировщике.
Вывод: upstream_response_time = 1.8s, приложение = 1.75s → проблема внутри сервиса.

Шаг 3. Глубинная диагностика: почему?

Включается фильтрация логов по endpoint="/api/checkout" и уровню ERROR/WARN;
В логах — повторяющееся сообщение: DB query timeout after 1500ms;
Корреляция с метриками БД:
- pg_stat_statements_mean_time для запроса SELECT * FROM orders WHERE user_id = ? AND status = 'pending' вырос с 50 мс до 1200 мс;
- pg_locks показывает рост waiting-блокировок.
Проверка индексов: отсутствует составной индекс по (user_id, status).

Реакция:

Экстренно: увеличение таймаута соединения к БД (временная мера);
Краткосрочно: добавление индекса (online DDL);
Долгосрочно: внедрение slow-query log с автоматическим алертом при duration > p95 * 2;
Профилактика: включение в CI/CD проверки плана запросов для всех новых миграций.

Ключевой принцип: искать узкое место в цепочке обработки.

Сценарий 2. Диск заполняется без видимой причины

Симптомы: алерт node_filesystem_avail_bytes < 10%, рост за последние 2 часа с 40 % до 3 %.

Шаг 1. Идентификация источника роста

Проверяется node_filesystem_size_bytes - node_filesystem_free_bytes по точкам монтирования — рост только в /var/log;
Запускается du -sh /var/log/* | sort -hr через агент (например, через Zabbix system.run[...] или Prometheus process-exporter с кастомным скриптом);
Вывод: /var/log/journal растёт со скоростью 2 ГБ/час.

Шаг 2. Анализ содержимого

Просмотр последних записей: journalctl --since "1 hour ago" | tail -n 100;
Обнаруживаются тысячи повторяющихся сообщений:
systemd[1]: Started Session c12345 of user nobody.
systemd[1]: Stopped Session c12345 of user nobody.
Поиск по session в логах: цикл запуска/остановки сессий каждые 2 секунды.

Шаг 3. Корреляция с сервисами

Проверка systemctl list-units --state=active | grep -E "(cron|timer)";
Обнаружен таймер cleanup-sessions.timer, запускающий скрипт каждые 5 секунд;
В скрипте — ошибка: вместо systemctl stop session-$ID он вызывает loginctl terminate-session $ID, что триггерит systemd на создание новой сессии.

Реакция:

Остановка таймера: systemctl stop cleanup-sessions.timer;
Очистка журнала: journalctl --vacuum-size=500M;
Исправление скрипта и тестирование в stage-среде;
Внедрение метрики rate(journal_messages_total{priority="info"}[5m]) с алертом при росте > 10× от baseline.

Ключевой принцип: скорость роста логов — сама по себе метрика стабильности; аномальный всплеск — сигнал о зацикливании или ошибке в автоматизации.

Сценарий 3. Периодические падения сервиса в ночное время

Симптомы: сервис недоступен ежедневно с 02:15 до 02:20, метрика up{job="api"} == 0.

Шаг 1. Исключение внешних факторов

Проверка других сервисов в том же кластере — работают;
Проверка инфраструктуры: CPU, память, сеть — в норме;
Вывод: проблема специфична для одного сервиса.

Шаг 2. Анализ временных меток

Точное время падения: 02:15:03 ± 2 сек;
Сравнение с расписанием:
- Cron: grep -r "15" /etc/cron* /var/spool/cron;
- Kubernetes CronJob: kubectl get cronjobs --all-namespaces;
Обнаружен daily-backup CronJob, запускающийся в 15 2 * * *.

Шаг 3. Диагностика задания

Логи CronJob: kubectl logs -l job-name=daily-backup-12345;
В логах — ошибка: pg_dump: error: too many connections;
Метрики БД: в 02:15 резкий всплеск pg_stat_activity_numbackends до max_connections;
Причина: бэкап-скрипт не использует пул соединений и запускает 50 параллельных pg_dump, каждый из которых открывает своё соединение.

Реакция:

Ограничение параллелизма в CronJob (parallelism: 1);
Настройка pg_dump с --jobs=4 и общим пулом;
Внедрение pre-check: перед запуском — проверка SELECT count(*) FROM pg_stat_activity WHERE state = 'active';
Добавление метрики cronjob_status{job="daily-backup"} с алертом при exit_code != 0.

Ключевой принцип: точное время инцидента — главная зацепка для поиска автоматизированных процессов; совпадение с расписанием почти всегда указывает на batch-задание.

Сценарий 4. Рост 5xx-ошибок без изменения кода

Симптомы: за 10 минут доля 5xx выросла с 0.1 % до 15 %, деплойей не было.

Шаг 1. Сегментация ошибок

Разбивка по статус-кодам: sum by (status) (rate(http_requests_total{status=~"5.."}[5m]));
95 % — 502 Bad Gateway, остальное — 504 Gateway Timeout;
Вывод: проблема на уровне шлюза (Nginx, API Gateway).

Шаг 2. Анализ upstream’ов

Метрики Nginx:
- nginx_upstream_response_time — рост до 30s;
- nginx_upstream_status{upstream="api", status="5xx"} — коррелирует с общим ростом;
- nginx_upstream_fails — резкий всплеск.
Проверка доступности upstream’ов: curl -s -o /dev/null -w "%{http_code}" http://api:8080/health;
Результат: 50 % запросов возвращают 500.

Шаг 3. Глубина в приложение

Логи api-сервиса: массовые ошибки Connection refused при подключении к redis;
Метрики Redis:
- redis_connected_clients — 0;
- redis_uptime_in_seconds — обнулился 12 минут назад.
Вывод: Redis перезапустился (возможно, OOM-killer).

Шаг 4. Причина перезапуска

Системные логи хоста: grep -i "killed process" /var/log/messages;
Запись: Out of memory: Kill process 12345 (redis-server).
Анализ использования памяти:
- redis_memory_used_bytes рос экспоненциально последние 24 часа;
- Причина: новый функционал начал кэшировать все сессии без TTL.

Реакция:

Экстренно: увеличение лимита памяти для Redis, установка maxmemory-policy=allkeys-lru;
Краткосрочно: добавление TTL к кэшируемым объектам;
Долгосрочно: введение метрики rate(redis_memory_used_bytes[1h]) с алертом при положительном тренде;
Профилактика: memory profiling в staging перед релизом.

Ключевой принцип: 5xx-ошибки на шлюзе — почти всегда означают проблему у upstream’а; диагностика должна идти «вглубь стека», а не «вширь сервисов».

Сценарий 5. Неудачные попытки входа в админку

Симптомы: алерт rate(failed_logins_total[5m]) > 10, исходящие из одного IP.

Шаг 1. Верификация инцидента

Проверка логов аутентификации:
- Linux: journalctl _COMM=sshd | grep "Failed password";
- Приложение: {service="admin-panel"} |~ "invalid credentials".
Подтверждение: 120 попыток за 3 минуты с 185.143.22.77.

Шаг 2. Оценка риска

Проверка:
- Использовался ли валидный логин? (... for user "admin");
- Есть ли успешные входы с этого IP ранее? (grep "Accepted" /var/log/auth.log | grep 185.143.22.77);
- Блокировка уже активна? (fail2ban-client status sshd).
Вывод: атака брутфорсом по известному логину admin, fail2ban не настроен.

Шаг 3. Реакция по протоколу

Немедленно:
- Блокировка IP на уровне фаервола: iptables -A INPUT -s 185.143.22.77 -j DROP;
- Сброс активных сессий: pkill -u admin (если вход был успешен).
Краткосрочно:
- Включение fail2ban с политикой maxretry = 3, bantime = 1d;
- Отключение входа под root и admin по паролю (только SSH-ключи).
Долгосрочно:
- Внедрение 2FA для админ-панелей;
- Мониторинг rate(failed_logins_total{login=~"^(admin|root|test)$"}) как индикатора целевых атак.

Ключевой принцип: события безопасности требуют технической и процедурной реакции; автоматизация (fail2ban) дополняется, но не заменяет ручной верификации.

Общая методология расследования (итоговая схема)

Любой инцидент можно диагностировать по единому алгоритму:

Шаг	Цель	Инструменты	Проверяемый вопрос
1. Подтверждение	Убедиться, что событие реально	Метрики доступности, логи, synthetic checks	«Это ошибка измерения или реальный инцидент?»
2. Сегментация	Выделить зону поражения	Фильтрация по меткам (service, instance, endpoint)	«Что именно нарушено? Где границы?»
3. Корреляция	Связать с другими событиями	Совмещение временных рядов, `trace_id`, события аудита	«Что происходило в системе в этот момент?»
4. Локализация	Найти узкое место	Сравнение метрик на границах компонентов (ingress → app → DB)	«Где возникает отклонение?»
5. Верификация гипотезы	Подтвердить причину	Логи (ошибки), профилирование, репликация в тестовой среде	«Почему это происходит?»
6. Реакция	Устранить и предотвратить	Runbook, автоматизированные действия, изменение кода/конфигурации	«Как остановить сейчас и не допустить в будущем?»

Эта схема не зависит от инструментов — она применима и в среде с Zabbix+rsyslog, и в cloud-native стеке с Prometheus+Loki+Tempo.

Метрика, мониторинг и логирование​

Стабильность​

Что такое стабильность системы​

Признаки нестабильности​

Измерение стабильности​

Метрики​

Мониторинг​

Как система выполняет измерения​

Pull-модель (опрос «снаружи»)​

Push-модель (передача «изнутри»)​

Гибридная модель​

Агенты​

SNMP​

Алертинг​

Логирование​

Уровни логирования​

Структурированное логирование​

Системные журналы в Linux​

systemd-journald​

rsyslog / syslog-ng​

Системные журналы в Windows​

Логи приложений​

Логи аудита​

Жизненный цикл логов​

Prometheus​

Архитектурные компоненты​

Модель данных и язык запросов​

Особенности развёртывания​

Zabbix​

Архитектура​

Модель конфигурации​

Особенности​

Grafana​

Ключевые возможности​

Архитектурные аспекты​

ELK Stack​

Почему Logstash уступает место Beats и Ingest Pipelines​

Модель данных и поиск​

Современные альтернативы и гибриды​

Три столпа наблюдаемости​

Стратегия построения системы наблюдаемости​

Этап 1. Базовая стабильность (реактивный мониторинг)​

Этап 2. Диагностическая глубина (корреляционный мониторинг)​

Этап 3. Проактивное управление (прогностический мониторинг)​

Этап 4. Наблюдаемость как часть жизненного цикла​

Анти-паттерны и типичные ошибки​

1. Алертинг по метрикам без контекста​

2. Логирование всего «на всякий случай»​

3. Отсутствие сквозной идентификации​

4. Мониторинг только «своего» компонента​

5. Игнорирование стоимости наблюдаемости​

Роль системного администратора в эпоху наблюдаемости​

Перспективы​

Практикум: типовые сценарии диагностики и реагирования​

Сценарий 1. Сервис стал отвечать медленно, но не падает​

Шаг 1. Уточнение: что замедлилось?​

Шаг 2. Локализация: где возникает задержка?​

Шаг 3. Глубинная диагностика: почему?​

Реакция:​

Сценарий 2. Диск заполняется без видимой причины​

Шаг 1. Идентификация источника роста​

Шаг 2. Анализ содержимого​

Шаг 3. Корреляция с сервисами​

Реакция:​

Сценарий 3. Периодические падения сервиса в ночное время​

Шаг 1. Исключение внешних факторов​

Шаг 2. Анализ временных меток​

Шаг 3. Диагностика задания​

Реакция:​

Сценарий 4. Рост 5xx-ошибок без изменения кода​

Шаг 1. Сегментация ошибок​

Шаг 2. Анализ upstream’ов​

Шаг 3. Глубина в приложение​

Шаг 4. Причина перезапуска​

Реакция:​

Сценарий 5. Неудачные попытки входа в админку​

Шаг 1. Верификация инцидента​

Шаг 2. Оценка риска​

Шаг 3. Реакция по протоколу​

Общая методология расследования (итоговая схема)​

Метрика, мониторинг и логирование

Стабильность

Что такое стабильность системы

Признаки нестабильности

Измерение стабильности

Метрики

Мониторинг

Как система выполняет измерения

Pull-модель (опрос «снаружи»)

Push-модель (передача «изнутри»)

Гибридная модель

Агенты

SNMP

Алертинг

Логирование

Уровни логирования

Структурированное логирование

Системные журналы в Linux

systemd-journald

rsyslog / syslog-ng

Системные журналы в Windows

Логи приложений

Логи аудита

Жизненный цикл логов

Prometheus

Архитектурные компоненты

Модель данных и язык запросов

Особенности развёртывания

Zabbix

Архитектура

Модель конфигурации

Особенности

Grafana

Ключевые возможности

Архитектурные аспекты

ELK Stack

Почему Logstash уступает место Beats и Ingest Pipelines

Модель данных и поиск

Современные альтернативы и гибриды

Три столпа наблюдаемости

Стратегия построения системы наблюдаемости

Этап 1. Базовая стабильность (реактивный мониторинг)

Этап 2. Диагностическая глубина (корреляционный мониторинг)

Этап 3. Проактивное управление (прогностический мониторинг)

Этап 4. Наблюдаемость как часть жизненного цикла

Анти-паттерны и типичные ошибки

1. Алертинг по метрикам без контекста

2. Логирование всего «на всякий случай»

3. Отсутствие сквозной идентификации

4. Мониторинг только «своего» компонента

5. Игнорирование стоимости наблюдаемости

Роль системного администратора в эпоху наблюдаемости

Перспективы

Практикум: типовые сценарии диагностики и реагирования

Сценарий 1. Сервис стал отвечать медленно, но не падает

Шаг 1. Уточнение: что замедлилось?

Шаг 2. Локализация: где возникает задержка?

Шаг 3. Глубинная диагностика: почему?

Реакция:

Сценарий 2. Диск заполняется без видимой причины

Шаг 1. Идентификация источника роста

Шаг 2. Анализ содержимого

Шаг 3. Корреляция с сервисами

Реакция:

Сценарий 3. Периодические падения сервиса в ночное время

Шаг 1. Исключение внешних факторов

Шаг 2. Анализ временных меток

Шаг 3. Диагностика задания

Реакция:

Сценарий 4. Рост 5xx-ошибок без изменения кода

Шаг 1. Сегментация ошибок

Шаг 2. Анализ upstream’ов

Шаг 3. Глубина в приложение

Шаг 4. Причина перезапуска

Реакция:

Сценарий 5. Неудачные попытки входа в админку

Шаг 1. Верификация инцидента

Шаг 2. Оценка риска

Шаг 3. Реакция по протоколу

Общая методология расследования (итоговая схема)